Recently, various classes of graphical programs have been used to describe computations that can be performed on application-specific computing hardware, such as a computer, microcontroller, FPGA, and custom hardware. Classes of such graphical programs may include time-based block diagrams, such as those found within Simulink® from The MathWorks, Inc. of Natick, Mass., state-based and flow diagrams such as those found within Stateflow® from The MathWorks, Inc. of Natick, Mass., and data-flow diagrams. A common characteristic among these various forms of graphical programs is that they define semantics on how to execute the programs.
A graphical program can be hierarchical so that the graphical program includes a subsystem. A subsystem refers to a collection of components that is represented by a single component with input and output signals. The input and output signals of the subsystem are accessible to the constituent components within the subsystem. The subsystem may also include another subsystem. In some conventional graphical programming environments, a hierarchical graphical program is displayed in a multi-window interface where clicking on a subsystem opens a new window displaying the content of the subsystem. The downside of this method is that when browsing many levels of hierarchy, many windows are opened and the user must carefully manage these windows. Otherwise, the user may suffer from window clutter. In other conventional graphical programming environments, the same window is used as the user navigates up and down the hierarchy of the graphical program. That is, the content of the subsystem is displayed in the same window as the parent graphical program. The downside of this method is that the user must use forward and backward buttons to go up and down the hierarchy and the user must normally constrain each level to fit in the size of the same window.
Additionally, other conventional graphical programming environments provide a textual hierarchical browser (often embedded within an integrated development environment) which shows the hierarchy of the graphical program. The downside of this approach is that the textual interface may not be the most natural in terms of how the user wants to navigate the graphical program. Furthermore, the conventional graphical programming environments have a problem with the display of results data. For example, a simulated block diagram may generate a vast amount of data logged in many display elements, and a corresponding number of windows have to be opened to display the data in the conventional graphical programming environments.